feat: per-request observability (method, latency, errors) - #12

The server had no per-request observability — only a startup line plus error/panic logs — so there was no way to see which LSP methods are called or how long they take. This adds request-level logging.

Change

ObserveHandler — a jsonrpc2 middleware (mirroring RecoverHandler) wrapping the server handler. For every request it logs:

• method (e.g. textDocument/completion)
• duration_ms — request body → reply, i.e. server processing time (not transport or queue wait; handlers are serialized by AsyncHandler)
• error — only when the request failed

It logs at Debug, so it's silent unless RIDL_LSP_LOG_LEVEL=debug, and writes only to the server logger (stderr → the editor's output channel). stdout is the JSON-RPC transport and is never logged to. Placed outermost (ObserveHandler(RecoverHandler(ServerHandler))) so even recovered-panic requests are timed and logged with their error.

Usage

Set RIDL_LSP_LOG_LEVEL=debug in the server's environment. Every request then logs a structured line, e.g. {"method":"textDocument/hover","duration_ms":1.83}.

Test plan

$ go test -race ./...
ok  ./...

$ golangci-lint run ./... -c .golangci.yml
0 issues.

New tests use zap's observer to assert the logged fields: method + duration_ms present on success (no error field), an error field on a failed request, and reply forwarding intact.

Not included (deliberate)

Aggregation (per-method p50/p95) and metrics export (Prometheus/OTel) were scoped out — this is the per-request log layer. Grep duration_ms for latency; aggregation can follow if needed.